Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Это статья нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS.

Виртуализация оборудования, также известная как серверная виртуализация, представляет собой абстракцию вычислительных ресурсов от программного обеспечения, которое использует эти ресурсы. В статье поговорим об истоках виртуализации и остановимся на ее аппаратной реализации.

В традиционной физической вычислительной среде ПО, такое как операционные системы или корпоративные приложения, имеет прямой доступ к базовому компьютерному оборудованию и компонентам, включая процессор, память, хранилище, некоторые чипсеты драйверы ОС. Ранее это создавало серьезные проблемы в настройке программного обеспечения, а также существенно затрудняло перемещение или переустановку приложений на другое оборудование — например при восстановлении из резервных копий после аварии.

Об истоках виртуализации

Термин «виртуализация» был придуман в конце 1960-х - начале 1970-х годов в ходе исследовательских проектов IBM и MIT в области совместного использования вычислительных ресурсов группами пользователей. Подробнее об этом вы можете почитать в нашем блоге на Хабре: [ССЫЛКИ на IBM/360 и истоки виртуализации].

В настоящее время виртуализация широко распространена в ИТ. В сфере облачных сервисов лидируют продукты компаний VMware, Microsoft, Citrix и Oracle.

Как работает аппаратная виртуализация

Процесс аппаратной виртуализации включает в себя установку гипервизора или диспетчера виртуальных машин (VMM). Именно они создают уровень абстракции между программным обеспечением и непосредственным «железом». После установки гипервизора программное обеспечение полагается на виртуальные представления вычислительных компонентов — то есть, к примеру, на виртуальные CPU вместо физических. К наиболее популярным гипервизорам можно отнести решения VMware vSphere на основе ESXi и Microsoft Hyper-V.

Виртуализированные вычислительные ресурсы объединяются в изолированные «группы», называемые виртуальными машинами (ВМ). На подготовленную ВМ можно установить операционную системы, а затем требуемые приложения. Виртуализированные системы могут иметь сразу несколько виртуальных машин одновременно, при этом каждая виртуальная машина логически изолирована от своих «соседей». Таким образом, если одна из ВМ подвергнется атаке вируса, будет перегружена или взломана, это никак не скажется на других машинах внутри системы.

Виртуализация позволяет бизнесу сократить издержки, связанные с приобретением серверного оборудования. К примеру, вместо покупки 10 разных серверов для размещения 10 приложений, каждому из которых для работы требуется отдельная ОС, достаточно построить виртуализированную систему, которая будет содержать требуемое количество ВМ, в рамках всего одного достаточно мощного сервера.

Традиционная архитектура в сравнении с виртуальной
https://searchservervirtualization.techtarget.com/definition/hardware-virtualization

Поскольку гипервизор устанавливается непосредственно на сервер, а операционные системы и ПО добавляются позже, такой подход часто называют виртуализацией «на голом железе». В последние годы гипервизоры стали самостоятельными узко заточенными ОС. Есть и альтернативный подход, работающий в случае, если вы не можете/не желаете работать с «голым железом» — сперва устанавливается главная операционная система, а уже в ней разворачивается гипервизор и все ВМ. Этот метод часто называют виртуализацией с хост-системой. Сейчас он чаще всего используется для виртуализации контейнеров.

Типы аппаратной виртуализации

Существует несколько типов аппаратной виртуализации. Среди них — полная виртуализация, паравиртуализация и виртуализация с аппаратной поддержкой. Кратко поговорим о каждом из них.

Полная виртуализация полностью имитирует требуемое оборудование для гостевой операционной системы. В итоге получается среда, аналогичная ОС, работающей на отдельном сервере. Использование полной виртуализации позволяет администраторам запускать виртуальные среды любых конфигураций без каких-либо дополнительных аппаратных ухищрений.

Паравиртуализацией называется подход, при котором на ВМ запускается особым образом подготовленная (измененная и/или перекомпилированная) версия гостевой ОС. Иными словами, системные администраторы должны соблюдать исходные требования ОС к железу лишь частично.

Виртуализация с аппаратной поддержкой использует аппаратное обеспечение компьютера в качестве «архитектурной поддержки» для создания полностью виртуализированной ВМ и управления ею. Виртуализация с аппаратной поддержкой была впервые представлена ??IBM в 1972 году с IBM System / 370. Виртуализация с аппаратной поддержкой на сегодняшний день является наиболее распространенной формой виртуализации.

Технология виртуализации дала жизнь популярным сейчас облачным сервисам, таким как:

• виртуальные VDS/VPS-серверы;
• IaaS, инфраструктура как услуга;
• терминальные серверы в облаке;
• VDI, виртуальная инфраструктура рабочих столов;
• cloud gaming и многим другим.

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

Если же заглянуть в список совместимости для vSphere, то там будет обозначена поддержка старого и нового драйверов:

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.

Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).

1. Миграция в два шага (Two-Step Migrations)

При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:

• Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
• Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.

Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.

2. Миграция в один шаг

Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.

Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.

Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:

Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.

Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:

На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:

1. VMware OS Optimization Tool билд b2001

Про прошлый апдейт этой утилиты мы писали вот тут. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

Что появилось нового:

• Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
• Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
• Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
• Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
• Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
• Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.

Скачать VMware OS Optimization Tool можно по этой ссылке.

2. vSphere Software Asset Management Tool версии 1.3

Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.

О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:

• Отображение продуктов семейства Tanzu в генерируемых отчетах
• Несколько исправлений ошибок

Скачать Software Asset Management Tool 1.3 можно по этой ссылке.

3. DRS Dump Insight версии 2.0

Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. 

Давайте посмотрим, что появилось нового:

• Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
• Доступен выбор нескольких отдельных дампов для анализа из общего списка
• Исправления ошибок и доработки бэкенда

Скачать DRS Dump Insight можно здесь.

4. Workspace ONE Discovery версии 1.1

Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).

Что появилось нового:

• Обновлена иконка приложения
• Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services

Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.

Компания VMware обновила свое руководство для быстрого старта с инфраструктурой виртуализации настольных ПК и приложений - Quick-Start Tutorial for VMware Horizon 8. Это один из самых популярных материалов на VMware TechZone на сегодняшний день, он позволяет начинающим администраторам VMware vSphere и Horizon развернуть тестовую VDI-среду в своей компании за пару часов.

VMware проделала значительную работу по оптимизации руководства, и теперь его объем сокращен с 222 страниц (для Horizon 7) до 63 страниц (Horizon 8). Все это позволяет быстро начать развертывание решения, а уже потом постигать детали.

То, что вы будете делать, в рамках прочтения руководства и развертывания продукта, будет выглядеть так:

Основные фазы будут следующего содержания:

• Install - начнете с установки Horizon Connection Server, который управляет сессиями пользователей для десктопов и приложений на базе веб-консоли Horizon Administrative Console.
• Prep - с использованием vSphere Client вы создадите образы Windows-десктопов, а также сервера RDSH для виртуализованных приложений. Кроме того, вы поставите Horizon Agent в гостевые ОС.
• Configure - создадите пул виртуальных ПК и ферму серверов с виртуализованными приложениями, а также назначите для них права доступа.
• Output - из iOS, Android, Chromebook, Windows, macOS или Linux подключитесь к виртуальным ПК, загрузив соответствующую версию Horizon Client или зайдя через браузер (HTML Access web client).

После выполнения всех описанных задач вы получите готовую инфраструктуру Horizon с несколькими опубликованными приложениями (на базе сервисов Microsoft Remote Desktop Session Host, RDSH), а также пул виртуальных десктопов на базе Windows 10.

Руководство Quick-Start Tutorial for VMware Horizon 8 доступно по этой ссылке.

Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.

Запускается утилита просто: vsantop

По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:

После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:

Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.

Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:

vsantop -b -d [delay] -n [iterations] > [file location & name]

usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
    -h prints this help menu.
    -v prints version.
    -b enables batch mode.
    -d sets the delay between updates in seconds.
    -n runs vsantop for only n iterations. Use "-n infinity" to run forever.

Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:

vsantop -b -d 10 -n 20 > /vmfs/volumes/vsanDatastore/vsantop/result.csv

VMware выпустила 2 новых экзамена VMware Certified Advanced Professional (VCAP)

На днях компания VMware объявила о релизе обновленных версий экзаменов VMware Certified Advanced Professional (VCAP). Первый - Advanced Design VMware vSphere 7.x (3V0-21.21) - подтверждает знание кандидатами принципов разработки концептуальной архитектуры VMware vSphere 7.x с учетом требований заказчика, возможность определения функциональных и нефункциональных требований для создания логического дизайна инфраструктуры, а также создания физической архитектуры с учетом всего этого.

Этот экзамен ведет к сертификации VMware Certified Advanced Professional – Data Center Virtualization Design 2021:

Экзамен содержит 60 вопросов и заданий, 300 очков проходной балл и 150 минут на сдачу. Описание экзамена (Blueprint) находится вот тут.

Второй выпущенный экзамен - это  Advanced Deploy VMware vSphere 7.x (3V0-22.21). Он проверяет знания по планированию и развертыванию решения vSphere 7.x, включая задачи по администрированию, оптимизации и траблшутингу. Тут уже больше про Day-2 Operations.

Экзамен требуется для сертификации VMware Certified Advanced Professional – Data Center Virtualization 2021 Deploy:

Здесь уже 17 заданий на базе лабораторных работ, 300 очков проходной балл и 205 минут на сдачу. Руководство по экзамену доступно тут.

Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...

Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.

Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.

Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.

SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.

Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.

Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).

Попробовать работу с движком SRS можно двумя путями:

1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)

2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).

Начать экспериментировать с SRS API можно, перейдя по ссылке:

https://{SRS-IP}/swagger/index.html

SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.

SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.

Вчера мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1c, где главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Один из главных сценариев такой миграции - это горячий перенос виртуальной машины из онпремизной инфраструктуры VMware vSphere в облачную среду VMC on AWS.

Для подобного рода миграций vMotion теперь есть 2 рабочих процесса: миграция ВМ на другой vCenter, а также импорт с целевого vCenter виртуальной машины источника:

Для функциональности XVM поддерживается и режим пакетной миграции, для которого вы можете указать несколько виртуальных машин, выбрать пункт Migrate и начать их одновременный перенос (пункт Cross vCenter Server export):

При миграции можно выбрать новый vCenter или один из уже сохраненных, что очень удобно при миграции групп ВМ в несколько заходов. К сожалению, Saved vCenters сохраняются только в рамках одной пользовательской сессии:

Дальше мастер будет похож на аналогичный в обычном vMotion, где будут выполняться стандартные предпроверки:

Как и при обычном vMotion, вы можете сменить хранилище виртуальной машины, а также ее сеть, чтобы она соответствовала инфраструктуре назначения. Затем начнется стандартная задача миграции:

На целевом vCenter тоже будет отображаться задача по приему vMotion от источника:

На целевом vCenter можно также самостоятельно инициировать прием миграции, выбрав пункт Import VMs из контекстного меню кластера:

Чтобы провести такую миграцию, также надо подключить исходный vCenter:

При успешном подключении вы сможете выбрать виртуальные машины, которые требуется перенести в другой датацентр:

Таким образом, эта функциональность может быть использована для следующих случаев:

• Миграция онпремизных ВМ в облачный датацентр VMC on AWS без необходимости настройки Hybrid Linked Mode (HLM)
• Переход на новую версию платформы vSphere путем переноса рабочих нагрузок со старых серверов
• Миграция ВМ в рамках обновления инфраструктуры VMware Cloud Foundation (VCF)
• Консолидация датацентров или перераспределение их содержимого
• Вывод из эксплуатации старого оборудования со старыми версиями vSphere
• Глобальная перебалансировка виртуальных машин между окружениями VCF
• Миграция инфраструктуры на одно из публичных облаков VMware Cloud

На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.

Давайте посмотрим, что именно:

• Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
• Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
• Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):

• Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
• Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
• Улучшения Supervisor Cluster:
  • Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
  • Поддержка NSX-T 3.1 для Supervisor Clusters
  • Удалена поддержка Supervisor Cluster версий 1.16.x.
• Улучшения служб Tanzu Kubernetes Grid for vSphere:
  • Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
  • Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
  • Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.

Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.

Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.

Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:

Insufficient resources

Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:

The target host does not support the virtual machine's current hardware requirements.

Также может быть показано следующее сообщение:

Feature 'MWAIT' was absent, but must be present.

Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.

Вариант 1:

Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.

Вариант 2:

1. Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
2. Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
3. Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
4. Выбираем Disable EVC.
5. Повторяем это для всех виртуальных машин.

Как многие администраторы уже знают, 31 декабря этого года прекращается официальная поддержка технологии Adobe Flash большинством браузеров. Это в первую очередь затрагивает VMware vSphere Web Client, использовавшийся для управления старыми версиями VMware vSphere, когда новая платформа vSphere Client на базе HTML5 еще только развивалась (сейчас это полнофункциональный клиент, а старого веб-клиента больше нет). Напомним, что ранее была прекращена поддержка Internet Explorer.

Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:

В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:

EOLUninstallDisable=1

EnabledAllowList=1

AllowListPreview=1

AllowListUrlPattern=https://FQDN/

Вместо FQDN нужно указать адрес вашего сервера vCenter, vCloud Director или веб-консоли другого продукта.

Вот где находится файл mms.cfg в зависимости от браузера и операционной системы:

Более подробно об этом рассказано в KB 78589.

На сайте компании Veeam появился кумулятивный Patch 3, который вы можете накатить на релиз продукта для резервного копирования и репликации виртуальных машин Veeam Backup and Replication 10a. Главная новая фича данного патча - это официальная поддержка новой версии платформы виртуализации VMware vSphere 7 Update 1.

Это уже третий кумулятивный патч после релиза версии 10а в июле этого года.

Давайте посмотрим на новые возможности, появившиеся в третьем патче к Veeam B&R v10a:

• Полная поддержка VMware vSphere 7.0 U1, включая обновленный vSphere API, а также виртуальных машин с Virtual Hardware 18.
• Автоматическое исключение из бэкапа системных ВМ, используемых службой vSphere Clustering Service (vCLS).
• Поддержка Microsoft Windows 10 20H2 и Microsoft Windows Server 20H2 как гостевых ОС, защищенных методом host-based backups и agent-based backups. Также туда можно поставить компоненты Veeam Backup & Replication.
• Поддержка дистрибутивов RHEL 8.3 и SLES 15 SP2 со стороны Veeam Agent for Linux 4.0.1.2372 - как в плане функций агента, так и в плане установки компонентов Veeam B&R.
• Добавлена поддержка S3-совместимого объектного хранилища со включенным версионированием и отключенным object lock (например, Backblaze B2).

Перед обновлением убедитесь, что номер билда вашей версии - это 10a (build 10.0.1.4854) в разделе Help -> About консоли Veeam Backup & Replication. После апгрейда номер билда должен измениться на 10.0.1.4854 P20201202.

Скачать Veeam Backup and Replication 10a Patch 3 можно по этой ссылке.

Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.

На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.

Например, из интересного:

• VMware vSphere Security Configuration Guide 7 (а также секция Security)
• vMotion Enhancements in vSphere 7 (а также секция vSphere)
• vSphere with Tanzu Proof of Concept и Quick Start Guides

Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.

Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:

Недавно у компании VMware появился интересный документ "Performance Characterization of NVMe-oF in vSphere 7.0 U1", в котором рассказывается о производительности протокола NVMe-oF (NVMe over Fibre Channel).

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.

Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).

Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:

Задержка (Latency) также снизилась практически в два раза:

На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:

Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!

Остальные интересные детали тестирования - в документе.

На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).

Работает это решение в двух средах:

• Интегрированные кластеры Tanzu Kubernetes Grid (TKG) K8
• Отдельные инсталляции кластеров K8 на платформах vSphere/AWS

После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:

Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.

Перед использованием данного средства вам понадобятся:

• Токен для vRealize LogInsight Cloud API
• Helm версии 3.x
• Административный доступ к кластеру Kubernetes

Итак, процедура по шагам:

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Получаем файл с переменными из рабочей директории:

helm show values loginsight-cloud/loginsight-cloud-helm > values.yaml

3. Обновляем параметры API Token и другие настройки, специфичные для вашей среды. Начинаем с команды:

cat values.yaml

4. Устанавливаем компонент Chart:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm -f values.yaml

5. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

6. Верифицируем релиз Helm:

helm list

Второй рабочий процесс установки (интерактивный режим):

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Устанавливаем Chart в интерактивном режиме:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm --set vrlic.apikey=SETME --set tag.environment=DEMO

3. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

4. Верифицируем релиз Helm:

helm list

После установки проверяем, что логи идут к LogInsight, это должно выглядеть следующим образом:

Чтобы начать пользоваться пробной бесплатной версией облака vRealize LogInsight Cloud, можно запросить триальную версию тут.

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины из облака в аренду. В 2016 году мы писали о решении VMware Cloud Foundation. По прошествии лет приведенную информацию следует актуализировать. В статье мы разберем примеры и кейсы его применения в реальных условиях.

Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:

1. Расширение томов PersistentVolumeClaim

В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.

2. Статический провижининг в Supervisor Cluster

Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).

3. Поддержка vVols для vSphere K8s и TKG Service

Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.

4. Функции Data Protection for Modern Applications

В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.

5. Функции vSAN Direct

Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.

Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.

Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.

1. Функции Network QoS для трафика резервного копирования

Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:

Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.

2. Улучшенная обработка задач резервного копирования

Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.

3.Улучшенное масштабирование для одновременно запущенных задач РК

Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.

4. Улучшения vSphere APIs for I/O Filtering (VAIO)

Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.

Теперь здесь появились следующие улучшения:

• CIM provider теперь стал 64-битным
• Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты

Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?

Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).

Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.

Собственно, таблица:

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.

Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.

В VMware vSphere 7, вместе с соответствующей версией VM Hardware, были существенно улучшены функции работы для режима vSGA, который предназначен для совместного использования графического адаптера несколькими виртуальными машинами хоста.

Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:

Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).

Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5, 6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.

Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.

Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.

Мы уже довольно много писали о нововведениях и улучшениях недавно обновленной версии платформы VMware vSphere 7 Update 1, а также средств создания отказоустойчивых кластеров VMware vSAN 7 Update 1. Между тем, наши читатели указывают нам на интересные нововведения в части функций по работе с хранилищами в апдейте платформы (Core Storage Enhancements).

Если вы хотите подробно почитать обо всех функциях хранилищ в vSphere 7 Update 1, то рекомендуем посмотреть вот этот документ - "vSphere Storage" (но там 400 страниц, имейте в виду):

Давайте посмотрим, что из нового заслуживает внимания:

1. Улучшения VMFS

Тут 2 основных момента:

• Процесс создания снапшота SESparse был улучшен - теперь он меньше раздувается, а также требуется меньше места в процессе консолидации снапшотов. Также улучшилось отображение прогресса консолидации.
• Уменьшилось время "замирания" файловой системы при создании или удалении снапшотов. Это произошло за счет доработки механизма взаимодействия Affinity Manager и Resource Clusters (RC).

2. Доработки томов vVols

• Поддержка томов vVols как основного хранилища для VMware Cloud Foundation (VCF).
• Поддержка томов vVols для Tanzu и Cloud Native Storage (CNS).
• Оптимизация миграций виртуальных машин и операций Storage vMotion для тонких дисков - это уменьшает время, необходимое на миграцию виртуальных машин между томами vVols.
• Оптимизация операций по привязке томов vVols - теперь при включении нескольких виртуальных машин одновременно эти операции выполняются в пакетном режиме, что увеличивает производительность за счет меньшего числа VASA API вызовов.
• Поддержка VASA для метода аутентификации CHAP на томах vVols через iSCSI.

3. Улучшения NFS

• Для NAS VAAI появилась возможность установки плагинов без перезагрузки.
• Раньше клонирование NVDK или LZT диска падало с ошибкой, теперь же для них все отрабатывает отлично.

4. Функция расширения pRDM со службами Microsoft WSFC

• Была добавлена поддержка горячего расширения disk/LUN для режима pass-through RDM, использующегося в кластерах Windows Server Failover Clustering (WSFC).

5. Функции NVMeoF

• Поддержка Oracle RAC при использовании таргетов NVMeoF

Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:

То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:

Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.

Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).

Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:

• Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
• Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
• Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.

Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.

Чтобы у вас работала технология PVRDMA для Native Endpoints:

• ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
• Гостевая ОС должна поддерживать RDMA namespaces на уровне ядра (Linux kernel 5.5 и более поздние).
• Виртуальная машина должна иметь версию VM Hardware 18 или более позднюю.

За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.

На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.

Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.

Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).

Для запуска тестовой среды вам понадобятся:

• python3
• sshpass
• 2 ГБ свободного места
• Linux-окружения (с версией ядра не менее 2.6.31)

Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:

Скачать Storage Performance Tester можно по этой ссылке.

Не так давно мы писали о том, что в последней версии VMware vSphere 7 Update 1 технология vMotion стала еще быстрее и теперь обеспечивает нужды горячей миграции даже для самых тяжелых виртуальных машин.

Напомним, что VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.

Недавно был выпущен интересный и полезный документ "vMotion Innovations in VMware vSphere 7.0 U1 - Performance Study", в котором VMware суммаризовала основные улучшения, сделанные в vMotion.

Интересны некоторые моменты. Например, в vSphere 6.7 используется технология отслеживания изменений CPU во время миграции stop-based trace, которая "подмораживает" все CPU, а в vSphere 7 U1 уже подмораживается только один процессор (техника loose page-trace Install):

Также vSphere 7.0 U1 передает compacted bitmap памяти вместо полного, что уменьшает время переключения на ВМ другого хоста:

Интересно уменьшение влияния миграции тяжелой БД Oracle на производительность - улучшение составило 19 раз!

Время миграции - до 50% меньше:

Ну и вообще в документе очень много всего интересного для интересующихся. Читайте здесь.

Wolfgang Taitl в своем блоге обратил внимание на серьезную проблему, касающуюся некоторых NFS-хранилищ и процесса создания резервных копий виртуальных машин на VMware ESXi. Это известная проблема.

Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.

Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.

При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.

После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:

• Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
• Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
• Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
• Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.

На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.